NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part2/13703

Internet Message Format | 1996-08-05 | 3.7 KB

Path: solon.com!not-for-mail
From: [e-mail] (J. Kanze)
Newsgroups: comp.lang.c,comp.lang.c.moderated,hp.unix,comp.sys.hp.apps,comp.sys.hp.hpux
Subject: Re: C coding problem
Date: 9 Apr 1996 17:39:35 -0500
Organization: GABI Software, Sarl.
Sender: [e-mail]
Approved: [e-mail]
Message-ID: <4keov7$[e-mail]>
References: <4j06na$[e-mail]> <4jttan$[e-mail]>
    <4jv6st$[e-mail]> <4k1qh3$[e-mail]>
NNTP-Posting-Host: solutions.solon.com

In article <4k1qh3$[e-mail]> [e-mail] writes:

|> In article <4jv6st$[e-mail]> [e-mail] (Konrad Schwarz) writes:
|> >
|> >|> a[i] is converted to *(a + i) by the compiler in any case so
|> >|> whats the advantage with your approach?
|> >
|> >The machine doesn't have to add, the machine doesn't have to multiply,
|> >*a is less complicated to understand than a [i] since only one variable
|> >is involved, *a is more type safe than a [i], since there is nothing
|> >constraining i (besides it being of integral type), the optimizer
|> >has less to do, compile time decreases, etc.

|> However it is not always so that the machine does a distinct
|> add or multiply in order to handle a[i].  The "*p++" idiom may look
|> shot in the C code, and on a PDP-11 it usually resulted in nice
|> short code.  However, there is no guarentee that this is true of all
|> hardware.  It is not all that uncommon to have an architecture where
|> adding 1 to an int is much cheaper than adding one to a pointer,
|> In such and environment,
|>       *q++ = *p++;
|> loses badly to
|>       q[i] = p[i], ++i;
|> if the hardware indexing works in terms of the objects being
|> referenced.

*Normally*, any decent compiler will convert either of these idioms to
whichever is fastest on that machine, although I do have memories of a
Microsoft C compiler which converted the array notation to pointers,
even though on the target machine (8086, large model), it could keep the
(single) index in memory, but not the pointers.  (Turning off
optimization resulted in a program that ran faster and was smaller.)

>From a compiler point of view, the array notation will normally result
in better optmization.  Sure, it gets converted into pointer arithmetic.
But since the compiler generates all of the operations on the pointers,
it knows the full constraints on them.  In practice, I doubt that this
will make a significant difference, however.

|> >Why use C if you're uncomfortable with pointer arithmetic?

Because that is the compiler that is available:-).

|> I don't think the original poster was uncomfortable with pointers.

|> There is a persistent folklore that says just because you code
|> something with pointers it is magically faster.  It is not true.
|> Sometimes using a pointers is faster, sometimes using subscripting is
|> faster.  Usually it makes MINISCULE difference.

|> The converse folklore is that subscripting is always more readable.
|> It is also untrue.  Pointer notation can greatly reduce program
|> clutter so you can see what is happening.

What is obfuscation is using pointers when the original data is an array
(or vice-versa).  (Another obfuscation is writing a loop when there is a
standard function which does the same thing.  The reader will probably
spend a significant amount of time trying to figure out why you didn't
use the function, and what you are doing differently.)
--
James Kanze           ([phone]          email: [e-mail]
GABI Software, Sarl., 8 rue des Francs Bourgeois, 67000 Strasbourg, France
Conseils en informatique industrielle --
                            -- Beratung in industrieller Datenverarbeitung